Network Working Group T. Rinne 
Request for Comments: 1756 HUT 
Category: Experimental January 1995 


REMOTE WRITE PROTOCOL - VERSION 1.0 
Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


1. Background 


It is often convenient to use electronic communication somewhat 
lighter than electronic mail. Sometimes even the use of the talk(1) 
*) program seems like overkill. We like to offer to user something 
like UNIX **) command write(1) ***) except that it can also pass 
messages through the network instead of the single host. 


There have been few programs offering this kind of service, but they 
have either based on SUN-RPC protocol or used a strictly undocumented 
protocol. 


This document describes a simple Remote Write Protocol (RWP) that 
should have been documented at least 10 years ago. But late is 
better than never. Version number of the RWP protocol in this 
document is 1.0. 


2. Overview 


RWP is a simple protocol that can be used to relay short messages 
through the network to other users. RWP looks pretty much like 
Simple Mail Transfer Protocol (SMTP) ****) though it is a bit more 
complicated due to the interactive nature of the RWP session. 


The idea behind the RWP session is that client program that is 
relaying message to the host in which the target user is logged in 
opens the tcp or udp connection to the server program running in the 
target machine Then the client gives the sender’s and recipient’s 
identification (usually login ids), actual message body and tells the 


server to deliver a message to the user. On tcp-connection server 
returns a status from each action taken. On udp-connection no 
responses are sent. RWP sessions through udp are implemented to 


support message broadcasting. 
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Message delivering methods are not defined within this document, but 
the basic method could be a simple write to users terminal. This is 
basically what UNIX command write(1) does. Depending on server 
implementation, the delivery method could be configurable personally 
by each user. 


3. Description 


Server program answers to each command submitted by a response. All 
responses have two parts: three number unique response code anda 
short textual explanation of the response. Also whenever the server 
is ready to accept new commands a notification is submitted to the 
client. 


There are three kinds of commands in RWP. The first group is for 
querying a status of the server. The second group is actual message 
handling commands and the last set of commands are for RWP session 
control. 


When the server is ready to receive a command from the client, it 
sends a message code 100 to the client. This message is for example 
as follows: 
100 Ready. 
Server commands are as follows: 
Status Query 
HELP Gives a short help message that contains legal 
RWP commands. Help lines have code 510. Example RWP 
implementation *****) gives a following response to 


HELP command: 


510 Valid commands are: 


510 BYE, DATA, HELP, HELO, 
510 RSET, SEND, PROT, QUIT, 
510 VRFY, VER 
510 FROM senderlogin 
510 FHST senderhost 
510 TO recipentlogin [tty] 
510 FWDS current_hop_count 
HELO Says hello to the server. Server response to HELO 


command has code 500. For example: 


500 Hello remote.host. This is local.host speaking. 
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PROT Asks the RWP protocol version from the server. 
Response code to PROT command is 502. Protocol 
version described in this document is RWP 1.0 and the 
response is as follows: 


502 RWP version 1.0. 


VRFY After the recipient of the message is set by to command 
described later, the possibility of message delivery 
can be queried by VRFY command. If message can be 
delivered the response code is 108. If message is 
about to be forwarded the response code is 110 and 
message is either form: 


110 Recipient ok to forward. 


or if the server can tell the destination of the 
forwarding: 


110 Recipient ok to forward <user@host.domain>. 


Other possible response codes are 669, 670, 671, 674 
and 677 and they all indicate that message delivery is 
by one way or another currently impossible. 
Description of the codes is later in this document. 


After the SEND command the server may also give 
autoreply from the remote user before the actual 
response code. Autoreply lines are ones of code 300. 


VER Asks the version of the server program. Response code 
to VER command is 501 and the textual part of the 
response is the name and the version number of the RWP 
server, for example: 


501 Rwrited version 1.0. 
Message Handling: 
FROM senderlogin 
Tells the server the identification information of the 
sender of the message. Usually this id information is 
user’s login id. Response code to successful FROM 


command is 105, for example: 


105 Sender ok. 
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TO recipentlogin [tty] 
Tells the server the identification information of the 
intended recipient of the message. Usually this id 
information is user’s login id. If tty is submitted, 
the message is delivered to that tty. If tty is 
submitted between brackets ’[]’ the tty given is 
treated as a hint only. Response code to successful 
TO command is 106. 


FHST original.host [forwarderl.host forwarder2.host ...] 
Tells the server the host name that the message 
originates to and the path of the hosts that has 
forwarded the message. The host name of the machine 
that is currently submitting the message to the server 
should not be in the path list. 


This information is relevant if message is forwarded 
and it is not originally coming from the host that is 
forwarding it. Response code to successful FHST 
command is 111. 


DATA Tells the server to start receive the body of the 
message. Response code to DATA command is 200, for 
example: 

200 Enter message. Single dot ’.’ on line terminates. 


After response 200 the message lines are submitted to 
the server one after another. Message is terminated 
by the line that contains a single dot ’.’. The 
termination of the message is acknowledged by the 
server with the response code 107. Server does not 
notify client about receiving the single message 
lines. If empty message is submitted (i.e. single dot 
is on the first line) the response code is 672 and 
DATA command only cancels possible previous DATA 
command. Because of this all dots or at least dots 
that are standing alone in the line have to be quoted. 


SEND Sends the message. If commands FROM, TO and DATA are 
successfully given before SEND command, the message is 
delivered to the target user. If delivery is 
successful the response code is 103. If message is 
not delivered directly to the target user but instead 
forwarded to another host the response code is 104. 
Response codes 669, 670 and 671, 677 indicate an error 
on message delivery and codes 673, 674, 675 indicate 
that either command FROM, TO or DATA has not been 
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successfully given before SEND command. After the 
SEND command the server may also give autoreply from 
the remote user before the actual response code. 
Autoreply lines are ones of code 300. 


Tells the server that message has been forwarded n 
times. If the server forwards the message to the 
another server, it increments the counter and tells 
the remote server the current count of forwards. 
Response code to the FWDS command is 110 if n is less 
than the server specific forward limit. If this limit 
is exceeded the response code is 676. If the response 
code is 676 the client can either quit the session and 
fail the message or it can give the message to the 
server despite the fact that the forward limit is 
exceeded. If the message is given when forward limit 
is exceeded, the server tries to deliver it, but does 
not forward it to another server. If forward count is 
given as -1, the message is considered as a autoreply 
and never forwarded. 


Session Control: 


RSET 


BYE 


QUIT 


Resets the RWP session. FROM, TO and DATA -commands 
that are given before are canceled and they have to 
be given again before SEND command can be used. Also 
possible FWDS and FHST commands are canceled. 


Terminates the RWP session. Server gives a response 
code 101 and closes the connection. 


Is the synonym to bye, but it’s a lot more impolite. 
Response code is however 101 as in bye. 


Server specific command: 


Rinne 


QUOTE command 


Relay a command to the server. If the QUOTE command 
is successfully completed response code 112 is 
returned. If QUOTE command is failed the response 
code is 678. If RWP server doesn’t recognize the 
given QUOTE command the response code is 679. 


Currently reserved QUOTE commands are AGENT, CHARSET, 
IDENT, KEY and KEYID. 
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4. Response Codes 
Here are all legal response codes of RWP server followed by short 
textual explanation. Only the numeral codes are important and texts 
can contain practically anything, however in response code 110 there 
is possibly useful information between ’<’ and ’>’ characters. No 
characters ’<’ or ’>’ should be present in other responses. Also 
response 502 has possibly interesting information about the RWP 
protocol version the server supports. 
100 Ready. 
The RWP server is ready to accept next command. 
101 Goodbye. 
The RWP server is closing connection. 


103 Message delivered. 


The SEND command is successfully completed and the message is 
delivered directly to its destination. 


104 Message forwarded. 


The SEND command is completed and message is forwarded to the 
user. 


105 Sender ok. 

The FROM command successful. 
106 Recipient ok. 

The TO command successful. 
107 Message ok. 

The DATA command successful. 
108 Recipient ok to send. 


The VRFY command successful and direct message delivery is 
possible. 


109 RSET ok. 


The RWP server has received the RSET command and reset itself. 
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110 Ok to forward. 
or 
110 Ok to forward <user@host.domain>. 


The VRFY command successful and direct message delivery by 
forwarding is possible. If response has also forwarding 
address the client can either forward the message itself or 
give it to server for forwarding. 


111 Original sender host ok. 


The FHST command successful and original sender host is set as 
given by the client. 


200 Enter message. Single dot ’.’ on line terminates. 


The RWP server is ready to receive the message. Single dot on 
message line terminates the message. 


300 |I’m not in right now but I’ll be back tomorrow 
300 Jat 8 o'clock a.m. 


Automatical response to the delivered message. Every line of 
this user defined reply message is delivered in its own 300 
line. Response code 300 lines may appear only after SEND 
command before response code 103 (message delivered). Client 
receiving autoreply 300 should show the text of the autoreply 
to the user. Actual autoreply line begins after the re 
-character in the line. 


500 Hello remote.host. This is local.host speaking. 
Response to the HELO command. This message can also occur in 
the beginning of the conversation without the VER command and 
it can be ignored. 

501 Rwrited version X.X. 
Response to the VER command. This message can also occur in 


the beginning of the conversation without the VER command and 
it can be ignored. 
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502 RWP version 1.0. 


Response to the VER command. This message can also occur in 
the beginning of the conversation without the VER command and 
it can be ignored. 


510 Valid commands are: 


510 BYE, DATA, HELP, HELO, 
510 RSET, SEND, PROT, QUIT, 
510 VRFY, VER 

510 FROM senderlogin 

510 FHST senderhost 

510 TO recipentlogin 

510 FWDS current_hop_count 


Response to the HELP command. 


511 Information to the user. 


Server specific informational response. These responses may 
occur anytime during the conversation. The client can ignore 
them. 


512 Debug information to the user. 
Server specific informational response. Reserved for server 
debugging. These messages may occur anytime during the 
conversation. The client can ignore them. 

666 FATAL ERROR! 
The RWP server got into the fatal error situation and is about 
to exit immediately. Client programs are strongly encouraged 
to close the connection. 

668 Syntax error. 
The RWP server has received an invalid command. 


669 Permission denied. 


The RWP server is unable to deliver the message because the 
target user has denied the send permission. 


670 User not logged in. 


The RWP server is unable to deliver the message because the 
target user is not logged in. 
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671 No such user. 
The RWP server is unable to deliver the message because the 
target user does not exist. Error code 670 can be used to 
replace this message. 

672 No message. 
The DATA command is terminated with empty message body. No 
SEND command can be executed before a new DATA command is 
given. 

673 FROM command required. 
Tried to give the SEND command before FROM. 

674 TO command required. 
Tried to give the SEND command before TO. 

675 DATA command required. 
Tried to give the SEND command before DATA. 

676 Forward limit exceeded. 
Response to the FWDS command that had an argument that 


exceeded the server specific limit of message forwarding 
steps. 


677 Unable to forward message. 
or 
677 Unable to forward message to <user@host.domain>. 


Response to the SEND or VRFY command if message forwarding is 
attempted and the server specific limit of message forwarding 
steps has been exceeded or if message forwarding has otherwise 
failed. If message forwarding fails with message 669, 670 or 
671, server will not use response 667 but gives response but 
instead it gives the response analogous with the error 
occured. If message 677 includes address the message was to 
be forwarded, the client may try to deliver it itself. 


698 Unknown error. 


RWP server has faced an internal error that is not fatal. 
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699 Unknown error. 
RWP server has faced an unknown error that is not fatal. 
5. RWP Compliant Software 


Simple RWP 1.0 compliant server and client software RWrite-1.1 will 
be available during the fall 1994. 


6. Security of RWP 


RWP version 1.0 does not offer any mean to verify the identity of the 
user connecting the RWP server program. It’s possible to identify 
the sender using ident-service, but not all hosts currently support 
that. This vulnerability is analogous with the weakness of the SMTP 
protocol. Cryptographic user verification and message hiding method 
is under development and is to be defined in RWP version 2.0 during 
the year 1995. 


RWP server also may offer a way to the intruder to get to know user 
ids within the target host by trying the TO and VRFY commands. This 
vulnerability is also present in SMTP. It is however possible to 
build servers so that they never give message 671 (no such user) but 
use response 670 (user not logged in) instead. 


Another way to increase security even within RWP-1.0 described in the 
document is to design RWP servers so that they do not deliver 
messages directly to user but instead connect to some kind of RWP 
agent process that is executed by each user willing to receive RWP 
messages. This user configurable message agent could then decide 
whether to deliver the message to the user and which way of delivery 
to use. Message agent is the best way to prevent hostile user from 
sending uncontrolled message flood to the user’s terminal. 


Sample implementation (RWrite-1.0) of the RWP server includes the 
support for user configuration files in which each user can either 
allow or deny messages from some user(s), host(s) or network 
domains(s). Support for message agents is currently under 
development. 


The user that is receiving the message should be able to define 


characters to be stripped from the incoming messages to prevent 
terminal mess-—up. 
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7. 


10. 


RWP Connection Type 


It is suggested that tcp (and udp) port 18 should be allocated for 
rwp in future versions of RFCs listing the reserved tcp/udp/rpc 
ports. Currently port 18 is assigned to the service called Message 
Send Protocol (msp) that is not known to be implemented. Actually 
port 18 is not currently defined at all in the /etc/services -file of 
the any common UNIX-like system. Entry for /etc/services -file is as 
follows 


rwrite 18/udp # RWP rwrite 
rwrite 18/tcp # RWP rwrite 


Given that RWP compliant daemon program is /usr/sbin/rwrited the 
entry for /etc/inetd.conf -file would be: 


rwrite stream tcp nowait nobody /usr/sbin/rwrited rwrited 
Character quotation 


To offer a safe method to transfer various character sets RWP defines 
a method to quote characters in both message and autoreply. RWP uses 
quotation similar to MIME ‘quoted-printable’ encoding. Quoted 
character is presented as a ’=’ -sign followed by a two character hex 
code. This means also that all ’=’-signs have to be quoted. 
Quotation is also needed when message contains a line with only a 
single dot ’.’ in it. 


For example: 

"\a’ -> =07 

r\t’ -> =09 
Security Considerations 
Security issues are not discussed in this memo. 
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